IBIS Macromodel Task Group Meeting date: 14 June 2016 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: * David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: * Steve Parker IBM * Luis Armenta Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Ambrish to check for a collaborator's feedback on his nearly ready new version of the Backchannel proposal. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Dan: Motion to approve the minutes. - Mike L.: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: New Redriver Flow BIRD: - Discussion: Fangyi reported that discussions had settled on the approach for the new flow, and he is currently converting the proposal into a BIRD. DUT_ref_term BIRD Draft: - Walter: [sharing draft 1 of the BIRD] - The boiler-plate requirements sections of this BIRD are identical to those from the earlier [Pin Reference] BIRD. - This approach simply introduces a new [Model] subparameter: DUT_ref_term. - It is set to one of four values specifying which reference terminal serves as the overall reference terminal (Pulldown_ref, Gnd_clamp_ref, Pullup_ref, Power_clamp_ref). - It defines the terminal from which all terminal voltages are measured. - You make those relative measurements in the simulator. - The "Other notes:" section describes how you adjust for the offset if the [* Reference] keyword corresponding to the specified reference terminal has a non-zero value. - Note that Bob would prefer to remove the introductory phrase, "If the reference terminal's corresponding DUT test condition voltage [* Reference] is not 0.0," since one could just add the offset all the time even if it is 0.0. - Discussion: Arpad noted that he would prefer to spell out "terminal" as opposed to "term" in the subparameter's name, because "term" could be an abbreviation of several different words. Bob said that he preferred "term" for brevity, but understood Arpad's point about clarity. Radek said he agreed with Arpad and added that he didn't like the "DUT" abbreviation in the subparameter's name either. - Discussion: Arpad asked if Ext_ref and/or some additional reserved terminal names, such as A_gnd from [External Model] and [External Circuit], should also be included as options for DUT_ref_term. Walter said only Ext_ref could be added easily, as it is defined in [Pin Mapping]. He noted that he liked the idea, but that Bob had asked him not to include Ext_ref as an option. Walter said he thought Ext_ref should be an option. Referring back to the RS-232 example, he said you might have +14 and -14V power rails, and there is a 0.0V external reference that is provided by another Pin. Ext_ref could be used to provide that 0V reference via [Pin Mapping]. Bob said he felt this would be a misapplication of the Ext_ref. Arpad asked why, and said that historically Ext_ref had been added when differential receivers were being adopted with a common reference instead of individual references, i.e., independent negative input pins for each receiver. Arpad and Walter noted that, as currently defined, [External Reference] is explicitly defined as a reference for Input receiver measurements. Bob said it was added because some buffers have a separate terminal for an external reference that may be created by a voltage divider or provided externally and is used as a reference for threshold measurements. He said that was its only application, and that is why it's declared as a separate supply. He said it was not intended for use with respect to I/V tables. Walter stated that it would work perfectly fine for this purpose as well. Walter said that an RS-232 would have +14 and -14 volt rails, and was also guaranteed to have some 0V terminal, which could be provided by Ext_ref. Bob said that Ext_ref was already declared as a separate POWER or GND type model, and that it did not actually exist as part of the RS-232 Signaling [Model] itself. He said it was used so the receiver had an alternative way of creating a reference that might be a different Pin from the power rail Pins used by the Model. Walter said that he couldn't see any distinction between what Bob was stating and this proposed new use of Ext_ref. - Discussion: Radek said he still didn't get the concept of what was proposed. He said that you define one of the 4 (or 5 if Ext_ref is added) choices as the reference terminal, and then say if the value of the [* Reference] is non-zero then you add that to the voltages measured relative to the reference terminal. He said it made no sense, for example, to say that you measured a potential difference of zero between two terminals and then added in some delta. Walter said that the offset methodology was designed to take into account the voltage value that was at the reference terminal at DUT time when the DUT threshold measurements were taken. He said you can only measure the potential difference between buffer terminals, and then you use the offset to convert those differences to the absolute values recorded in the IBIS thresholds, etc., which are based on the DUT conditions. - Discussion: Radek pointed out that Ext_ref is only defined for receivers, so relying on it would not solve the issue for drivers. Walter agreed with this point and said Ext_ref might have to be extended. Radek still favored having the actual local ground (0V) reference terminal explicitly defined. Walter proposed that we might say Ext_ref is valid for inputs and outputs, and then require that for any IBIS [Model] one of the five [* Reference] DUT values must be 0.0. Radek thought this was one possible approach, but IBIS currently had no requirements of that nature. Bob objected to this suggestion. He said that he was fine with adding Ext_ref, but that RS-232, for example, could be handled perfectly well without using Ext_ref to provide the 0v terminal. He felt the offset approach could be used, for example defining the -14V rail as the reference terminal and using the -14V offset approach could provide a properly functional solution without explicitly providing the 0V local ground terminal. - Discussion: Arpad asked that we not mix too many additional changes and proposals into the discussion. Radek agreed and said that while requiring one of the five [* Reference] values to be 0.0 would solve this issue, it was a drastic change to the spec. Walter said he would simply update draft 1 to add Ext_ref as a possible terminal and add [External Reference] to the list of values in the "other notes:" section. Arpad and Bob were in favor of this, and Bob noted his general agreement with the BIRD. Walter noted that this discussion had grown out of interconnect task group discussions related to getting everything to work with package models and floating grounds, etc. He said that at this point everything was working well, unless we had a [Model] in which none of the [* Reference] values were zero. In that case, we still don't cover power aware simulations properly. Arpad noted that he recalled that case would cause problems with respect to Vinl, Vinh , threshold values in general, but he thought that the power integrity related keywords ([Composite Current], [ISSO *]) were among the only ones that already were properly defined with respect to referencing. - Curtis: Motion to adjourn. - Mike L.: Second. - Arpad: Thank you all for joining. AR: Walter to update the BIRD draft to produce draft 2. ------------- Next meeting: 21 June 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives